System and Methodology for Asynchronous Code Refactoring with Symbol 

Injection 

DESCRIPTION 

Cross Reference to Related Applications 

[Para 1] The present application Is related to the following commonly- 
owned, presently-pending applicatlon(s): application serial no. 10/209,283 
(Docket No. BORL/0204.01), filed July 30, 2002, entitled "System and 
Methodology Providing Compiler-Assisted Refactoring". The disclosure of the 
foregoing application is hereby incorporated by reference in its entirety, 
including any appendices or attachments thereof, for all purposes. 

Copyright Statement 

[Para 2] A portion of the disclosure of this patent document contains 
material which is subject to copyright protection. The copyright owner has no 
objection to the facsimile reproduction by anyone of the patent document or 
the patent disclosure as it appears in the Patent and Trademark Office patent 
file or records, but otherwise reserves all copyright rights whatsoever. 

Appendix Data 

[Para 3] Computer Program Listing Appendix under Sec. 1 .52(e): This 
application includes a transmittal under 37 C.F.R. Sec. 1 .52(e) of a Computer 
Program Listing Appendix. The Appendix, which comprises text file(s) that are 
IBM-PC machine and Microsoft Windows Operating System compatible, 
includes the below-listed file(s). All of the material disclosed in the Computer 
Program Listing Appendix can be found at the U.S. Patent and Trademark 
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Office archives and is hereby incorporated by reference into the present 
application. 

[Para 4] Object Description: SourceCode.txt, size 1 7.2KB, created 
8/24/2004, 5:02pm; Object ID: File No. 1 ; Object Contents: Source Code. 

Background of Invention 

[Para 5] 1 . Field of the Invention 

[Para 6] The present invention relates generally to a system providing 
methods for facilitating development and maintenance of software applications 
or systems, with particular emphasis on a system and methodology for 
asynchronous code refactoring. 

[Para 7] 2. Description of the Background Art 

[Para 8] Before a digital computer may accomplish a desired task, it must 
receive an appropriate set of instructions. Executed by the computer's 
microprocessor, these instructions, collectively referred to as a "computer 
program," direct the operation of the computer. Expectedly, the computer 
must understand the instructions which it receives before it may undertake the 
specified activity. 

[Para 9] Owing to their digital nature, computers essentially only understand 
"machine code," i.e., the low-level, minute instructions for performing specific 
tasks — the sequence of ones and zeros that are interpreted as specific 
instructions by the computer's microprocessor. Since machine language or 
machine code is the only language computers actually understand, all other 
programming languages represent ways of structuring human language so 
that humans can get computers to perform specific tasks. While it is possible 
for humans to compose meaningful programs in machine code, practically all 
software development today employs one or more of the available 
programming languages. The most widely used programming languages are 
the "high-level" languages, such C++, Pascal, or more recently Java and C#. 
These languages allow data structures and algorithms to be expressed in a 
style of writing that is easily read and understood by fellow programmers. 
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[Para 10] A program called a "compiler" translates these instructions into the 
requisite machine language. In the context of this translation, the program 
written In the high-level language Is called the "source code" or source 
program. 

[Para 1 1] The ultimate output of the compiler is a compiled module such as a 
compiled C++ "object module," which includes instructions for execution 
ultimately by a target processor, or a compiled Java class, which includes 
bytecodes for execution ultimately by a Java virtual machine. A Java compiler 
generates platform-neutral "bytecodes" — an architecturally neutral, 
intermediate format designed for deploying application code efficiently to 
multiple platforms. 

[Para 12] Integrated development environments, such as Borland's JBuilder 
(registered trademark), Delphi (trademark) and C# Builder (trademark), are the 
preferred application development environments for quickly creating 
production applications. Such environments are characterized by an 
integrated development environment (IDE) providing a form painter, a property 
getter/setter manager ("inspector"), a project manager, a tool palette (with 
objects which the user can drag and drop on forms), an editor, a debugger, 
and a compiler. In general operation, the user "paints" objects on one or more 
forms, using the form painter. Attributes and properties of the objects on the 
forms can be modified using the property manager or Inspector. In 
conjunction with this operation, the user attaches or associates program code 
with particular objects on the screen (e.g., button object). Typically, code Is 
generated by the IDE in response to user actions in the form painter and the 
user then manipulates the generated code using the editor. Changes made by 
the user to code In the editor are reflected in the form painter, and vice versa. 
After the program code has been developed, the compiler is used to generate 
binary code (e.g., Java bytecode) for execution on a machine (e.g., a Java 
virtual machine). 

[Para 1 3] Although integrated development environments facilitate the 
development of applications, issues remain in the development and use of 
such applications. One problem is that when a large software program or 
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application evolves over time it is common that the initial design gets lost as 
features that were not in the original specification are added to the application. 
One way of dealing with this problem of making changes is to design 
everything with the maximum amount of flexibility. However, this will often 
lead to unnecessary complexity in the software application, as It is unknown 
beforehand which parts of the application will require this additional flexibility. 
Irrespective of how well a system is initially designed or developed, the system 
is typically modified from time to time during its useful life to improve 
performance, to accommodate changing needs, to make the system easier to 
maintain, or for various other reasons. 

[Para 14] "Refactoring" Is a practice of making structured changes to software 
applications or systems which add the desired flexibility, but keep the 
functionality of the system the same. Refactoring involves taking small 
individual steps that are well defined and that can be applied in succession to 
yield more significant changes. For example, a developer may wish to perform 
a "rename refactoring" to change the name of a particular module (e.g., a class 
name in a Java program). In order to make this change, the user must locate 
the definition of this class (i.e., the source code for the class) as well as all 
uses of the class in other portions of the system. In the case of a class name 
in a Java program, the class name is typically used not only for defining a 
variable, but also for constructing instances (or objects) of that class and 
accessing static members of the class (i.e., class variables). Another example 
of refactoring may involve moving a specified class to a new package (referred 
to as "move refactoring"). 

[Para 1 5] Refactoring of a system may be small or extensive, but even small 
changes can introduce errors or "defects" into the system. Accordingly, 
refactoring must be done correctly and completely in order to be effective. 
Good refactoring requires a mechanism for quickly and accurately identifying 
definitions and usage of a given symbol in a plurality of source files. The 
"symbols" that may be involved in refactoring include, for example, package 
names, class names, Interfaces, methods, fields, variables, and properties. 
Identification of definitions and usage of a given symbol enables refactoring to 



Page 4 of 74 



be performed responsibly and durably so that no defects are introduced and 
no behavior is changed beyond the desired improvements in features, 
performance, and/or maintainability. 

[Para 1 6] A particular problem in refactoring a complex application or system 
is that the application or system may be made up of a number of different 
modules that are separately developed. Conventionally, creation of a software 
application or system includes creation of individual source code modules. 
This approach simplifies program development by dividing functionality 
available in the program into separate source modules. It should be noted that 
for purposes of the following discussion the terms "source code" or "source" 
will refer to source code or any kind of intermediate language representation 
(IR) of a program. When multiple source modules are employed for creating a 
program, interdependencies between the individual modules often exist. 
Program logic in a first module can, for instance, reference variables, methods, 
objects, and symbols imported from a second module. By the very same 
token, the first module can also export its own methods, objects, and symbols, 
making them available for use by other modules. Because of 
interdependencies between modules, when a particular source module is 
refactored (e.g., by a developer), the developer must ensure that the 
modifications made during the refactoring are compatible with the other 
modules of the program. A particular concern is, therefore, that the changes 
made during the refactoring might "break" the system, because the change is 
incompatible with other, dependent modules of the system. 

[Para 1 7] A common problem in the lifecycle of a software system is the 
ability to change application programming interfaces (APIs) In libraries. Any 
change of the API in a library which may result from changing source(s) of the 
library may result in errors in the parsing/attribution of the clients of this 
library (hereinafter "dependents"). This may limit or prevent the execution of 
traditional refactorlngs for the library. For example, a system may include 
both a library and a separate application module that uses (I.e., is dependent 
upon) the library. In this case the refactoring of the library may affect the 
application that is dependent upon the library. Generally, In this environment 
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If refactoring occurs In one module (e.g., the library), then it must also be 
applied to the other module(s) that are dependent on It (e.g., the application 
module In this example). 

[Para 1 8] Consider the same example of a library that has one or more 
applications dependent upon it. The library may, for example, be written and 
supplied by one company or organization and used by one or more other 
organizations in various applications. These applications that are written 
using the library are dependent upon the library. Accordingly, If the library is 
refactored, the dependent applications will be out of sync with the library and 
compilation errors may occur when they attempt to use the library. Unless the 
refactoring relates only to internal aspects of the library that are not used by 
any dependent applications, when the library is refactored, corresponding 
changes also need to be made to dependent applications. 

[Para 1 9] The following discussion will use an example of one or more 
applications that are dependent upon a library. However, it should be noted 
this Is only one example of items of software that are dependent upon one 
another. Other examples include, but are not limited to: a client portion of an 
application and a server portion of the application as well as a user interface 
(Ul) portion of a system and a non-UI portion of the system. Various different 
source components of a software system (e.g., application) may be developed 
by different developers that may be geographically distributed in different 
parts of the world. When these components are integrated into a system they 
need to work with each other and changes made to one component may 
Impact other components of the system. 

[Para 20] This problem is typically addressed in one of the following ways In 
current systems. One approach Is to manually refactor the source dependent 
module(s) to Implement the same changes made to the refactored dependee 
module. For Instance, In the case of a refactoring of a library on which an 
application is dependent, this would generally involve building the application 
against the refactored library to find compiler errors and then manually 
identifying and fixing all of these errors. Disadvantages of this approach 
include that this manual refactoring solution is both tedious and error prone. 
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A developer has to find all the errors (e.g., by building the application against 
the library and finding compiler errors) and then manually fix them. He or she 
might miss some of the errors or may otherwise introduce incorrect behavior. 
In some cases the application may compile, even though underlying errors 
remain that were not addressed. Another problem is the possibility that new 
errors may be introduced during the manual fix-up process. 

[Para 21] Another possible approach is to modify the library (dependee 
module) in such a way that the old behavior is maintained. For example, it 
may possible to do so by providing for duplication in the refactored library. 
This may involve retaining the existing functionality (before the refactoring) in 
the library so as to continue to provide support to any dependent modules 
(e.g., the application in this example). The new or additional functionality 
provided by the refactoring would then also be provided — for example with 
different names and with somewhat different behavior. 

[Para 22] Another similar alternative is to provide an abstract layer between 
the application and the (newly refactored) library. The abstract layer can serve 
to forward the calls to the appropriate routines of the refactored library. 
However, this approach also adds considerable complexity to the library and 
may serve to make the refactoring impractical in many cases. Disadvantages 
of these approaches of supporting multiple interfaces or to retrofitting support 
for old versions into the newly refactored library include that they will cause 
the library to become more complex and, therefore, may also make it more 
fragile and susceptible to error. Use of either of these approaches also makes 
the library more difficult to design and implement and may take away many of 
the advantages of refactoring the library in the first place. 

[Para 23] This is, in fact, another common alternative. In order to avoid these 
type of compatibility problems, users often simply elect not to perform any 
refactoring of the library (or other dependee module) in the first place. This 
avoids the above-described compatibility problems, but has the disadvantage 
of limiting the ability to implement needed changes. 

[Para 24] What is needed is a solution that facilitates refactoring of a plurality 
of interdependent modules. The solution should enable refactorings of these 
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moduies to be performed even though the modules may be included in 
separate projects. The solution should also automate the refactoring process 
so as to improve productivity and reduce the possibility of error. Ideally, the 
solution should enable a first program or module to be refactored at one time 
and at a later date facilitate the application of the appropriate changes to a 
second module that is dependent upon the first one. The present invention 
provides a solution for these and other needs. 

Summary of Invention 

[Para 25] A system and methodology for asynchronous code refactoring with 
symbol injection is described. In one embodiment, for example, a method of 
the present invention is described for refactoring a plurality of interdependent 
software modules that reside in separate projects, the method comprises steps 
of: in response to a change that affects a particular symbol of a software 
module that resides in a first project, refactoring the software module of the 
first project to propagate the change to all instances of the particular symbol 
in the software module; during the refactoring of the software module of the 
first project, recording meta data about the refactoring that is required to 
effect the change; and automatically propagating the change to a dependent 
software module residing in a second project, by refactoring the dependent 
software module based on the recorded meta data about the refactoring that 
occurred to the software module of the first project. 

[Para 26] In another embodiment, for example, a system of the present 
invention for automatically applying a refactoring to a second software module 
based on a refactoring of a first software module is described that comprises: 
a recording module for recording information about changes made to the first 
software module during a refactoring of the first software module; an injector 
module for copying symbol information about at least one symbol of the first 
software module into a symbol table for the second software module; and a 
refactoring module for automatically applying a refactoring to the second 
software module using the symbol table and the recorded information about 
changes made to the first software module. 
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[Para 27] In yet another embodiment, for example, a method of the present 
Invention is described for asynchronous refactoring of a plurality of 
interdependent software programs, the method comprises steps of: refactoring 
a first software program so as to change symbols of the first software 
program; recording information about changes made to symbols of the first 
software program during the refactoring of the first software program; and 
subsequently, applying the refactoring to a second software program 
dependent upon the first software program by automatically propagating 
changes to symbols of the second software program based on the recorded 
information. 

[Para 28] In another embodiment, for example, a method of the present 
invention is described for applying a refactoring to a plurality of software 
modules, the method comprises steps of: recording information about 
changes made to a first software module during a refactoring of the first 
software module; creating at least one symbol table entry based upon the 
recorded Information about changes made to the first software module; 
Injecting the at least one symbol table entry into a symbol table for a second 
software module; and refactoring the second software module using the 
symbol table and the recorded information about changes made to the first 
software module. 

Brief Description of Drawings 

[Para 29] Fig. 1 is a very general block diagram of a computer system (e.g., an 
IBM-compatible system) in which software-implemented processes of the 
present invention may be embodied. 

[Para 30] Fig. 2 is a block diagram of a software system for controlling the 
operation of the computer system. 

[Para 31] Fig. 3A is a high-level block diagram illustrating a Java development 
system suitable for implementing the present invention. 

[Para 32] Fig. 3B is a block diagram illustrating the virtual machine of Fig. 3A 
in further detail. 
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[Para 33] Fig. 4 is a liigli-level flow diagram illustrating the process of 
performing an asynchronous refactoring of two interdependent modules. 

[Para 34] Fig. 5A Is a screenshot of the development or programming 
interface including a distributed refactorings window provided in the currently 
preferred embodiment of the present invention. 

[Para 35] Fig. 5B Is a screenshot of the development or programming 
interface Including a refactoring history window provided In the currently 
preferred embodiment of the present Invention. 

[Para 36] Fig. 6 is a flowchart illustrating the methodology of the present 
Invention for refactoring of a dependent module with direct injection of one or 
more symbols into symbol tables. 

[Para 37] Fig. 7 Is a flowchart Illustrating the methodology of the present 
invention for refactoring of a dependent module with Indirect Injection of 
symbols Into symbol tables. 

Detailed Description 
[Para 38] Glossary 

[Para 39] The following definitions are offered for purposes of Illustration, not 
limitation, in order to assist with understanding the discussion that follows. 

[Para 40] Bytecode: A virtual machine executes virtual machine low-level code 
instructions called bytecodes. Both the Sun Microsystems Java virtual machine 
and the Microsoft .NET virtual machine provide a compiler to transform the 
respective source program (I.e., ajava program or a C# program, respectively) 
into virtual machine bytecodes. 

[Para 41] Compiler: A compiler Is a program which translates source code Into 
binary code to be executed by a computer. The compiler derives Its name 
from the way It works, looking at the entire piece of source code and collecting 
and reorganizing the Instructions. Thus, a compiler differs from an interpreter 
which analyzes and executes each line of code in succession, without looking 
at the entire program. A "Java compiler" translates source code written in the 
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Java programming language into bytecode for the Java virtual machine. For 
general background on the construction and operation of compilers, see e.g., 
Fischer et al., "Crafting a Compiler with C", Benjamin/Cummings Publishing 
Company, Inc., 1991, the disclosure of which is hereby incorporated by 
reference for purposes of illustrating the state of the art. 

[Para 42] Java: Java is a general purpose programming language developed by 
Sun Microsystems. Java is an object-oriented language similar to C++, but 
simplified to eliminate language features that cause common programming 
errors. Java source code files (files with a .Java extension) are compiled into a 
format called bytecode (files with a .class extension), which can then be 
executed by a Java interpreter. Compiled Java code can run on most 
computers because Java interpreters and runtime environments, known as Java 
virtual machines (VMs), exist for most operating systems, including UNIX, the 
Macintosh OS, and Windows. Bytecode can also be converted directly into 
machine language instructions by a just-in-time OIT) compiler. Further 
description of the Java Language environment can be found in the technical, 
trade, and patent literature; see e.g., Gosling, J. et al., "The Java Language 
Environment: A White PaperV'-Sun Microsystems Computer Company, October 
1 995, the disclosure of which is hereby incorporated by reference. For 
additional information on the Java programming language (e.g., version 2), see 
e.g., "Java 2 SDK, Standard Edition Documentation, version 1 .4.2," from Sun 
Microsystems, the disclosure of which is hereby incorporated by reference. A 
copy of this documentation is available via the Internet (e.g., currently at 
java.sun.com/j2se/ 1 .4.2 /docs/index.html). 

[Para 43] XML: XML stands for Extensible Markup Language, a specification 
developed by the World Wide Web Consortium (W3C). XML is a pared-down 
version of the Standard Generalized Markup Language (SGML), a system for 
organizing and tagging elements of a document. XML is designed especially 
for Web documents. It allows designers to create their own customized tags, 
enabling the definition, transmission, validation, and interpretation of data 
between applications and between organizations. For further description of 
XML, see e.g., "Extensible Markup Language (XML) 1 .0", (2nd Edition, October 
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6, 2000) a recommended specification from the W3C, the disclosure of which 
is hereby incorporated by reference. A copy of this specification is available 
via the Internet (e.g., currently at www.w3.org /TR/REC-xml). 

Introduction 

[Para 44] Referring to the figures, exemplary embodiments of the invention 
will now be described. The following description will focus on the presently 
preferred embodiment of the present invention, which Is implemented in 
desktop and/or server software (e.g., driver, application, or the like) operating 
In an Internet-connected environment running under an operating system, 
such as the Microsoft Windows operating system. The present invention, 
however, Is not limited to any one particular application or any particular 
environment. Instead, those skilled In the art will find that the system and 
methods of the present Invention may be advantageously embodied on a 
variety of different platforms, including Macintosh, Linux, Solaris, UNIX, 
FreeBSD, and the like. Therefore, the description of the exemplary 
embodiments that follows is for purposes of illustration and not limitation. 
The exemplary embodiments are primarily described with reference to block 
diagrams or flowcharts. As to the flowcharts, each block within the flowcharts 
represents both a method step and an apparatus element for performing the 
method step. Depending upon the implementation, the corresponding 
apparatus element may be configured In hardware, software, firmware, or 
combinations thereof. 

Computer-based implementation 

[Para 45] Basic system hardware (e.g., for desktop and server computers) 

[Para 46] The present Invention may be Implemented on a conventional or 
general-purpose computer system, such as an IBM-compatible personal 
computer (PC) or server computer. Fig. 1 is a very general block diagram of a 
computer system (e.g., an IBM-compatible system) in which software- 
Implemented processes of the present Invention may be embodied. As shown, 
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system 100 comprises a central processing unit(s) (CPU) or processor(s) 101 
coupled to a random-access memory (RAIVl) 1 02, a read-only memory (ROIVI) 
1 03, a keyboard 1 06, a printer 1 07, a pointing device 1 08, a display or video 
adapter 1 04 connected to a display device 1 05, a removable (mass) storage 
device 1 1 5 (e.g., floppy disk, CD-ROM, CD-R, CD-RW, DVD, or the like), a 
fixed (mass) storage device 1 1 6 (e.g., hard disk), a communication (COMM) 
port(s) or interface(s) 1 1 0, a modem 1 1 2, and a network Interface card (NIC) or 
controller 1 1 1 (e.g., Ethernet). Although not shown separately, a real time 
system clock Is included with the system 100, in a conventional manner. 

[Para 47] CPU 1 01 comprises a processor of the Intel Pentium family of 
microprocessors. However, any other suitable processor may be utilized for 
implementing the present Invention. The CPU 101 communicates with other 
components of the system via a bi-directional system bus (Including any 
necessary Input/output (I/O) controller circuitry and other "glue" logic). The 
bus, which includes address lines for addressing system memory, provides 
data transfer between and among the various components. Description of 
Pentium-class microprocessors and their Instruction set, bus architecture, and 
control lines Is available from Intel Corporation of Santa Clara, CA. Random- 
access memory 1 02 serves as the working memory for the CPU 101. In a 
typical configuration, RAM of sixty-four megabytes or more Is employed. 
More or less memory may be used without departing from the scope of the 
present invention. The read-only memory (ROM) 103 contains the basic 
input/output system code (BIOS) — a set of low-level routines in the ROM that 
application programs and the operating systems can use to Interact with the 
hardware, Including reading characters from the keyboard, outputting 
characters to printers, and so forth. 

[Para 48] Mass storage devices 115, 116 provide persistent storage on fixed 
and removable media, such as magnetic, optical or magnetic-optical storage 
systems, flash memory, or any other available mass storage technology. The 
mass storage may be shared on a network, or it may be a dedicated mass 
storage. As shown In Fig. 1 , fixed storage 1 1 6 stores a body of program and 
data for directing operation of the computer system, Including an operating 
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system, user application programs, driver and other support files, as well as 
other data files of all sorts. Typically, the fixed storage 1 16 serves as the main 
hard disk for the system. 

[Para 49] In basic operation, program logic (including that which implements 
methodology of the present invention described below) is loaded from the 
removable storage 1 1 5 or fixed storage 1 16 into the main (RAM) memory 102, 
for execution by the CPU 1 01 . During operation of the program logic, the 
system 100 accepts user input from a keyboard 106 and pointing device 108, 
as well as speech-based input from a voice recognition system (not shown). 
The keyboard 1 06 permits selection of application programs, entry of 
keyboard-based Input or data, and selection and manipulation of individual 
data objects displayed on the screen or display device 1 05. Likewise, the 
pointing device 108, such as a mouse, track ball, pen device, or the like, 
permits selection and manipulation of objects on the display device. In this 
manner, these input devices support manual user input for any process 
running on the system. 

[Para 50] The computer system 1 00 displays text and /or graphic images and 
other data on the display device 1 05. The video adapter 1 04, which is 
interposed between the display 105 and the system's bus, drives the display 
device 1 05. The video adapter 1 04, which includes video memory accessible 
to the CPU 1 01 , provides circuitry that converts pixel data stored in the video 
memory to a raster signal suitable for use by a cathode ray tube (CRT) raster or 
liquid crystal display (LCD) monitor. A hard copy of the displayed information, 
or other Information within the system 1 00, may be obtained from the printer 
1 07, or other output device. Printer 1 07 may include, for instance, an HP 
LaserJet printer (available from Hewlett Packard of Palo Alto, CA), for creating 
hard copy images of output of the system. 

[Para 51] The system itself communicates with other devices (e.g., other 
computers) via the network interface card (NIC) 1 1 1 connected to a network 
(e.g., Ethernet network, Bluetooth wireless network, or the like), and/or 
modem 1 12 (e.g., 56K baud, ISDN, DSL, or cable modem), examples of which 
are available from 3Com of Santa Clara, CA. The system 100 may also 
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communicate with local occasionally-connected devices (e.g., serial cable- 
linked devices) via the communication (COMM) interface 1 10, which may 
Include a RS-232 serial port, a Universal Serial Bus (USB) interface, or the like. 
Devices that will be commonly connected locally to the interface 1 1 0 include 
laptop computers, handheld organizers, digital cameras, and the like. 

[Para 52] IBM-compatible personal computers and server computers are 
available from a variety of vendors. Representative vendors include Dell 
Computers of Round Rock, TX, Hewlett-Packard of Palo Alto, CA, and IBM of 
Armonk, NY. Other suitable computers include Apple-compatible computers 
(e.g., Macintosh), which are available from Apple Computer of Cupertino, CA, 
and Sun Solaris workstations, which are available from Sun Microsystems of 
Mountain View, CA. 

[Para 53] Basic system software 

[Para 54] Fig. 2 is a block diagram of a software system for controlling the 
operation of the computer system 100. As shown, a computer software 
system 200 is provided for directing the operation of the computer system 
1 00. Software system 200, which is stored in system memory (RAM) 1 02 and 
on fixed storage (e.g., hard disk) 1 16, includes a kernel or operating system 
(OS) 210. The OS 21 0 manages low-level aspects of computer operation, 
including managing execution of processes, memory allocation, file input and 
output (I/O), and device I/O. One or more application programs, such as client 
application software or "programs" 201 (e.g., 201a, 201 b, 201c, 201 d) may be 
"loaded" (i.e., transferred from fixed storage 1 16 into memory 102) for 
execution by the system 100. The applications or other software intended for 
use on the computer system 1 00 may also be stored as a set of downloadable 
processor-executable instructions, for example, for downloading and 
installation from an Internet location (e.g., Web server). 

[Para 55] Software system 200 includes a graphical user interface (GUI) 215, 
for receiving user commands and data in a graphical (e.g., "point-and-click") 
fashion. These inputs, in turn, may be acted upon by the system 100 in 
accordance with instructions from operating system 210, and/or client 
application module(s) 201 . The GUI 21 5 also serves to display the results of 
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operation from the OS 21 0 and application(s) 201 , whereupon the user may 
supply additional inputs or terminate the session. Typically, the OS 210 
operates in conjunction with device drivers 220 (e.g., "Winsock" driver — 
Windows' implementation of a TCP/IP stack) and the system BIOS microcode 
230 (i.e., ROM-based microcode), particularly when interfacing with peripheral 
devices. OS 210 can be provided by a conventional operating system, such as 
Microsoft Windows 9x, Microsoft Windows NT, Microsoft Windows 2000, or 
Microsoft Windows XP, all available from Microsoft Corporation of Redmond, 
WA. Alternatively, OS 21 0 can also be an alternative operating system, such as 
the previously mentioned operating systems. 

[Para 56] Java development environment 

[Para 57] Java is a simple, object-oriented language which supports multi- 
thread processing and garbage collection. Although the language is based on 
C++, a superset of C, it is much simpler. More importantly, Java programs are 
"compiled" into a binary format that can be executed on many different 
platforms without recompllation. A typical Java system comprises the 
following set of interrelated technologies: a language specification; a compiler 
for the Java language that produces bytecodes from an abstract, stack- 
oriented machine; a virtual machine (VM) program that interprets the 
bytecodes at runtime; a set of class libraries; a runtime environment that 
includes bytecode verification, multi-threading, and garbage collection; 
supporting development tools, such as a bytecode disassembler; and a 
browser (e.g.. Sun's "Hot Java" browser). 

[Para 58] Fig. 3A is a high-level block diagram illustrating a Java development 
system 300 suitable for implementing the present invention. As shown, the 
Java development system 300 includes a client 310 which employs a virtual 
machine 320 for executing programs. In particular, the client 310 executes a 
"compiled" (i.e., bytecode or pseudo-compiled) Java program 340, which has 
been created by compiling a Java source code program or script 305 with a 
Java compiler 330. Here, the Java source code program 305 is an application 
program written in the Java programming language; the pseudo-compiled 
program 340, on the other hand, comprises the bytecode emitted by the 
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compiler 330. The virtual machine 320 includes a runtime interpreter for 
interpreting the Java bytecode program 340. During operation, the client 310 
simply requests the virtual machine 320 to execute a particular Java compiled 
program. 

[Para 59] During development of a software program, a user typically edits 
source listings which are displayed in a text editor or similar editing surface of 
the development system. Specifically, "symbols" which comprise the source 
listings are displayed on the editing surface. The symbols are the basic 
constructs which are employed for developing software (e.g., application 
software). The source listings are then compiled into a software program, 
such as application or system software. Needless to say, a program of even 
modest complexity will have numerous symbols which somehow must be 
managed by the programmer. And for object-oriented programming systems 
in particular, the symbols will often comprise a complex hierarchy — one which 
may be conceptually difficult to visualize. 

[Para 60] Compilation of source code typically involves several related 
operations. First, the input stream is scanned to break the source code files 
into a sequence of tokens or meaningful groups of characters. After scanning, 
the sequence of tokens is parsed to generate an abstract syntax tree or "parse 
tree" representation of the source code. Every programming language has a 
syntax — a set of grammar rules which specifies how statements and 
expression in that language are correctly written. A language's syntax dictates 
how compilers and interpreters translate programs. Knowledge about a source 
language's syntax is usually built into the "parser" of a compiler. The parser 
controls the translation process, since it analyzes the source program based 
on the syntax. The structure of a parser's routines is dictated largely from the 
syntax or formal grammar of the underlying language. The syntax describes 
how sentences can be formed in a general way. The parser's subroutines use 
the grammar to build the "parse tree" representation, which is a convenient 
way for a computer to represent the source listings. 

[Para 61] The parsing process also generally includes resolution of symbol 
declarations as well as semantic analysis to verify the source code as a 
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sequence of valid statements or expressions In the applicable programming 
language. The compiler also builds a symbol table and other supporting data 
structures for annotating each node in the parse tree with parse or type 
information. The output from these scanning and parsing operations is a 
parse tree in which nodes are annotated with either type or symbol 
Information. Following these scanning and parsing operations, the annotated 
parse tree is usually optimized by a code optimizer to optimize data references 
globally within a program. After optimization, a code generator generates 
Instructions or binary code for the target processor. Code generation may also 
include additional machine-dependent optimization of the program. Following 
compilation, the object code may also be "linl<ed" or combined with runtime 
libraries (e.g., standard runtime library functions) to generate executable 
program(s), which may be executed by a target processor. The runtime 
libraries include previously compiled standard routines, such as graphics, 
input/output (I/O) routines, startup code, math libraries, and the like. The 
result of the above process is that the high level source code files have been 
translated Into machine readable binary code which may then be executed. 

[Para 62] For general background on the construction and operation of 
compilers, see e.g., Fischer et a!., "Crafting a Compiler with C", 
Benjamln/Cummings Publishing Company, Inc., 1991, the disclosure of which 
is hereby incorporated by reference for purposes of Illustrating the state of the 
art. 

[Para 63] Also shown at Fig. 3A is the modification of the development system 
300 to implement the present invention. As shown, a refactoring module 335 
is provided for implementing the methodology of the present invention for 
asynchronous refactoring and symbol injection. The asynchronous refactoring 
operations of the system are described in detail below. 

[Para 64] Fig. 3B is a block diagram illustrating the virtual machine 320 of Fig. 
3A in further detail. As shown in Fig. 3B, the virtual machine 320 comprises a 
class loader 321 , a bytecode verifier 322, a bytecode interpreter 323, and 
runtime support libraries 324. The class loader 321 is responsible for 
unpacking the class file which has been requested by a client. Specifically, the 
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class loader 321 will unpack different sections of a file and instantiate in- 
memory corresponding data structures. The class loader will invoke itself 
recursively for loading any superclasses of the current class which is being 
unpacked. 

[Para 65] The bytecode verifier 322 verifies the bytecode as follows. First, it 
checks whether the class has the correct access level. Since the class will 
access other classes for invoking their methods, the bytecode verifier 322 
must confirm that appropriate access is in place. Additionally, the bytecode 
verifier confirms that the bytecode which comprises the methods is not itself 
corrupt. In this regard, the bytecode verifier confirms that the bytecode does 
not change the state of the virtual machine (e.g., by manipulating pointers). 
[Para 66] Once the bytecode has been verified, a "class initializer" method is 
executed. It serves, in effect, as a constructor for the class. The initializer is 
not a constructor in the sense that it is used to construct an instance of a class 
~ an object. The class initializer, in contrast, initializes the static variables of 
the class. These static variables comprise the variables which are present only 
once (i.e., only one instance), for all objects of the class. 
[Para 67] Runtime support libraries 324 comprise functions (typically, written 
in C) which provide runtime support to the virtual machine, including memory 
management, synchronization, type checking, and interface invocation. At the 
client machine on which a Java application is to be executed, runtime support 
libraries 324 are included as part of the virtual machine; the libraries are not 
included as part of the Java application. The bytecode which is executed 
repeatedly calls into the runtime support libraries 324 for invoking various 
Java runtime functions. 

[Para 68] In the currently preferred embodiment, the Java development 
system 300 may be provided by Borland JBuilder (registered trademark) 10.0, 
available from Borland Software Corporation of Scotts Valley, CA. Further 
description of the development system 300 may be found in "Building 
Applications with JBuilder UBuilder 10)" (Part No. JXEOOl 0WW21 OOSbajb). also 
available from Borland Software Corporation, the disclosure of which is hereby 
incorporated by reference. 
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[Para 69] The above-described computer hardware and software are 
presented for purposes of illustrating the basic underlying desktop and server 
computer components that may be employed for implementing the present 
invention. For purposes of discussion, the following description will present 
examples in which it will be assumed that there exists at least one computer 
running applications developed using the Java programming language. The 
present invention, however, is not limited to any particular environment or 
device configuration. In particular, use of the Java programming language is 
not necessary to the invention, but is simply used to provide a framework for 
discussion. Instead, the present invention may be implemented in any type of 
system architecture or processing environment capable of supporting the 
methodologies of the present invention presented in detail below. The 
following description will focus on those features of the development system 
300 which are helpful for understanding the methodology of the present 
invention for asynchronous refactoring. 

Overview of system and methodology for asynchronous refactoring 

[Para 70] The present invention comprises a system providing methodology 
for performing an asynchronous refactoring of interdependent modules of a 
system. The present invention enables users to perform a refactoring of a first 
module (e.g., a library) at one point in time and to apply the same refactoring 
to another dependent module (e.g., an application dependent on the library) at 
a later time. The refactoring process is automated so as to avoid manually 
refactoring the dependent module, which can be tedious and error prone. The 
following discussion will use examples of one or more applications that are 
dependent upon a library for purposes of illustrating the operation of the 
present invention. However, as described above this is only one example of 
dependent modules with which the present invention may be utilized. Those 
skilled in the art will appreciate that the methodology of the present invention 
may be used with various different types of interdependent components 
including, for example, a client component of an application and a server 
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component of an application or a user interface component of a system and a 
non-UI component of a system. 

[Para 71] The general approach of the present invention for asynchronous 
refactoring of two (or more) dependent modules can be summarized as 
follows. When an original (or first) refactoring of a first (or "dependee") 
software module (e.g., a first software module or program which resides in a 
first project) is performed, meta information regarding the refactoring is 
recorded (e.g., tracked and persistently stored). The meta information that is 
recorded about the refactoring of the dependee includes, but is not limited to, 
any particular "symbol(s)" being affected by the refactoring and the specifics of 
the changes that are made. For purposes of this document, the term 
"symbol(s)" refers to any type of language symbol(s), including, but not limited 
to class symbols, method symbols, variable symbols, and function symbols 
(sometimes hereinafter referred to as ClassSymbol, MethodSymbol, 
VariableSymbol, FunctionSymbol, respectively). Subsequently, when one or 
more "dependent" module(s) are refactored (e.g., a second software module 
residing in a second project), the system of the present invention performs the 
refactoring based on the recorded meta information. This serves to apply the 
corresponding changes to the dependent module(s) necessary to maintain 
compatibility with the refactored dependee module. 

[Para 72] The recorded refactoring meta information is applied to the 
dependent module(s) in two phases or sets of operations. In the first phase, 
entries for or more symbols are copied (or injected) into the symbol table (e.g., 
compiler symbol table) used for building the dependent module (e.g., 
application) based on the recorded refactoring meta information. In the 
second phase, the actual refactoring of the dependent module(s) is performed, 
using a conventional refactoring on the dependent module(s) that were fixed 
up in the first phase. Each of these phases are described below in greater 
detail. 

[Para 73] In the first phase, all symbol(s) from the dependee affected by its 
refactoring are patched by removing and /or injecting necessary structures that 
allow parsing of the refactored symbols. The dependent application's source 
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refers to "outdated" symbols that no longer exist in the dependee (i.e., 
because of refactoring of the dependee module). Accordingly, in this first 
phase a set of temporary symbols are created to temporarily represent the 
"outdated" symbols during the refactoring of the dependent application. For 
example, if a class has been renamed, symbol information regarding the 
outdated name of the class (i.e., the name before rename refactoring) is 
inserted in the correct namespace. Similarly, if a method has been removed 
(or added), or the method's signature has been changed during the refactoring 
of the dependee, the appropriate information is added or changed (as 
appropriate) so that the dependent sources can be parsed /attributed. It 
should be noted that the methodology of the present invention does not 
require actually patching all symbols to enable the dependent sources to be 
parsed without error. For instance, in a given situation there may be a number 
of refactorings to be applied and the present invention enables these 
refactorings to be performed one at a time. In some cases, such as the case 
involving the injection of a ClassSymbol, all symbol table entries for the 
affected class may be fixed up. However, If a program is refactored one 
method at a time, the present Invention provides for injecting a symbol table 
entry for only the method that is being refactored. 

[Para 74] In the second phase, the source(s) of the dependent application are 
parsed /attributed and a refactoring Is automatically propagated (or applied) to 
the dependent based on the refactoring previously performed on the 
dependee. Existing tools and utilities may be used In the second phase to 
perform the actual refactoring of the dependent application (or module) based 
on the recorded Information about the refactoring of the dependee. It should 
be noted that either the original refactoring of the dependee or any 
subsequent refactoring of dependent module(s) can performed using the 
compiler-assisted refactoring system and methodology described in 
commonly-owned, co-pending U.S. Patent application 10/209,283 titled 
"System and Methodology Providing Compiler-Assisted Refactoring" (Docket 
No. BORL/0204.01), the disclosure of which is hereby incorporated by 
reference. However, the use of this compiler-assisted refactoring system and 
methodology for performing these refactorings is not required, and these 
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refactorings can also be performed using other refactoring tools and utilities. 
For example, other IDEs with refactoring support suitable for use in 
conjunction with the present invention include IntelliJ from JetBrains of Prague, 
Czech Republic, Eclipse available from the Eclipse Foundation (a non-profit, 
industry consortium), and Borland Delphi(trademark) from assignee Borland 
Software Corporation of Scotts Valley, CA. 

[Para 75] The following is a simple example illustrating this process. In a 
traditional refactoring, one starts with an existing program (e.g., a library) 
which may include several classes and methods. For example, the library may 
include a class "MyNamespace::OldClass". The refactoring of the library may 
involve a rename refactoring in which the name of this class is changed to 
"MyNamespace::NewClass". The methodology of the present invention 
provides that information about this refactoring is recorded (in any form). The 
recorded information includes that the class "MyNamespace::OldClass" has 
been renamed to "MyNamespace::NewClass". 

[Para 76] If the above library is used by an application, the application may be 
affected by the refactoring of the library. For example, the application may 
include references to the "MyNamespace::OldClass" class of the library which 
need to be updated. The present invention provides for asynchronous 
refactoring of the application to maintain compatibility with the refactored 
library. When refactoring the application as part of this process, the 
application will likely not compile if run against the refactored library. The 
present invention provides for applying an asynchronous refactoring in this 
situation as described below. 

[Para 77] In applying an asynchronous refactoring to the application, the class 
"MyNamespace::OldClass" is first injected in the classes symbol table used by 
the parser/attributor. In this fashion, the old version of the library is fixed up 
to facilitate the refactoring of the application that is dependent on the library. 
In this case, a symbol entry for "MyNamespace::OldClass" is temporarily 
inserted in the symbol table (e.g., the compiler symbol table) so that the 
application can be compiled and the refactoring can be performed in an 
automated fashion. The sources of the dependent application referring to 
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"MyNamespace::OldClass" are then parsed and a conventional refactoring is 
applied to them, so that the class is renamed to "MyNamespace::NewClass". 

[Para 78] The present invention is particularly useful in automating the 
process of resolving and fixing errors due to changes in library API(s). The 
solution takes the refactoring paradigm to a new level, providing a quick and 
easy way to react to changes in a library (or other dependee source(s)) on 
which a program is dependent. The present invention removes many of the 
error factors and frustrations which may arise when this process is performed 
manually. As a result, it can save developer time and effort in making changes 
during the lifecycle of a software project, thereby increasing productivity. The 
present invention is also particularly useful to distributors of libraries and 
other such programs as it allows these distributors to change the public API(s) 
to their programs while providing an automated way for their users to adapt to 
these changes. 

System components 

[Para 79] Fig. 4 is a high-level flow diagram 400 illustrating the process of 
performing an asynchronous refactoring of two interdependent modules. The 
present invention may be used for performing two (or more) separate 
refactorings of various modules that may have interdependences. To 
illustrate the operations of the present invention, the following discussion 
describes the asynchronous refactoring of two modules: a dependee module 
(e.g., a library), and a single dependent module (e.g., an application dependent 
on the library). However, the system and methodology of the present 
Invention may be used for performing a plurality of refactorings of various 
types of interdependent modules. The following discussion also uses some 
examples of the refactoring of a software application written in the Java 
programming language. However, the reference to Java is only to provide a 
framework for discussion and the system and methodology of the present 
invention may also be used for refactoring of software systems written in a 
variety of programming languages. 
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[Para 80] As shown, the process begins at 401 with the performance of a 
refactoring of a first or "dependee" module (e.g., a library). The module to be 
refactored may comprise one or more source files or listings. The source files 
may, for instance, comprise a particular software library that has been 
developed to perform particular tasks. The source files may have been 
developed using a visual development system such as Borland JBuilder 
(registered trademark)or Borland Delphi (trademark) (both available from 
assignee Borland Software Corporation of Scotts Valley, CA). Alternatively, the 
source files may be developed using a text editor or another type of 
development tool and compiled using a compiler. The refactoring itself that is 
performed at 401 may be performed using the compiler-assisted refactoring 
system and methodology referenced above. Alternatively, the refactoring may 
be performed using another refactoring tool or utility, as desired. 

[Para 81] At 402, information about the refactoring of the library (dependee) 
is recorded. When the refactoring is performed (e.g., refactoring of the library 
using this example), meta information about the refactoring is collected. 
Typically, the collected information is written out and persisted (i.e., 
persistently stored) so that later this information can be used for a subsequent 
refactoring of a dependent module. However, the collected information could 
alternatively be streamed out to one or more dependent modules so that the 
refactoring of the dependent modules could occur almost in real time, if 
desired. 

[Para 82] In the next stage, the collected information about the refactoring is 
used for performing a refactoring of another module (e.g., a dependent 
application). The system and methodology of the present invention enables a 
user to apply the same refactoring to the dependent application (module) 
using the collected information. This second refactoring is typically performed 
some period of time after completion of the initial refactoring. It should be 
noted that this second refactoring could be applied to another module running 
on the same machine at which the original refactoring was performed or on a 
different machine at a different location. Also, the dependent module (e.g.. 
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application) may be written using tlie same programming language or a 
different programming language than the dependee module (e.g., library). 

[Para 83] At 403, the recorded meta information about the refactoring of the 
dependee module (e.g., the library) is read. Optionally, information about the 
refactoring may be presented to the user at 404. In the currently preferred 
embodiment of the present Invention, a menu option is provided to present a 
list of refactorings that have been performed in dependee modules (e.g., in the 
library). Currently, a list of all of the refactorings that have been performed 
and those that have also been applied to the current module (e.g., the 
dependent application) is displayed. The user can then select a refactoring 
from the list of refactorings that have already been performed for refactoring 
of a dependent module. This menu option is provided in the system user 
interface for the convenience of users; however, it Is not required for 
implementation of the present Invention. 

[Para 84] When a refactoring of the dependent module is initiated, the 
refactoring is performed in two general phases. First, entries for one or more 
symbol(s) are injected (i.e., copied) into the symbol table(s) (e.g., compiler 
symbol table) based upon the recorded meta information about the original 
refactoring at 405. In this example, entries for the symbol(s) are injected into 
the symbol table(s) used by the application based on the recorded information 
from the refactoring of the library. The recorded refactoring information is 
converted appropriately for the type of refactoring engine that is being used. 
For example, the refactoring could be performed with the assistance of the 
compiler or using another kind of refactoring engine or utility. Entries for the 
symbols are injected into appropriate tables so that it is possible to apply a 
normal refactoring. It should be noted that the injection of entries for symbols 
into a compiler symbol table is not required for implementation of the present 
invention. The symbols need to be recorded, tracked, and reused, but a 
different type of table can be used instead of a compiler symbol table. 

[Para 85] In the currently preferred embodiment of the present invention, 
there are two different mechanisms provided for injection of symbols: one for 
directly injecting entries for symbols into symbol table(s) and a second for 
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doing so in an indirect fashion. The indirect approach involves creating one or 
more "stub" source file(s) based on the collected refactoring information to 
represent the "outdated" version of the dependee module (e.g., the version of 
the library prior to the refactoring). When this "stub" source file(s) is 
parsed/attributed, entry(ies) for the symbol(s) are injected into the symbol 
table as a side effect. It should be noted that the symbol table entries as well 
as any stub source files that are created are only temporary and are removed 
when the refactoring is complete. 

[Para 86] After the injection of symbol(s), the second phase of the refactoring 
process proceeds. The actual refactoring of the application (i.e., the 
dependent module) is then performed as illustrated at 406. The refactoring 
that is performed is a conventional refactoring that is performed based on the 
recorded refactoring Information. The present invention, in its currently 
preferred embodiment, employs the compiler-assisted refactoring system and 
methodology described in commonly-owned, co-pending U.S. Patent 
application serial number 10/209,283 titled "System and Methodology 
Providing Compiler-Assisted Refactoring", above. However, another tool or 
utility may be used for performing the refactoring, as desired. When the 
refactoring is complete, the temporary symbol entries injected into the table(s) 
are removed and the process is complete. 

[Para 87] As described above, the asynchronous refactoring methodology of 
the present invention involves several new steps or operations as compared to 
a conventional refactoring of a single module. These additional operations 
include collecting/recording meta information about the original refactoring, 
reading the recorded meta information (e.g., at a later time), and injecting 
entries for symbol(s) into symbol table(s) based on the recorded meta 
information. The original refactoring (e.g., of the library at step 401) is 
essentially conventional except for the addition of the recording of meta 
information about the refactoring. The last step (step 406) of refactoring the 
application uses the meta information about the original refactoring to ensure 
that the appropriate changes are applied to the dependent module. These 
operations are described below in more detail. 
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Detailed operation 

[Para 88] The following description presents method steps that may be 
implemented using processor-executable instructions, for directing operation 
of a device under processor control. The processor-executable instructions 
may be stored on a computer-readable medium, such as CD, DVD, flash 
memory, or the like. The processor-executable instructions may also be 
stored as a set of downloadable processor-executable instructions, for 
example, for downloading and installation from an Internet location (e.g., Web 
server). 

[Para 89] Recording and reading meta information regarding original 
refactoring 

[Para 90] When a dependee module is refactored, information about this 
refactoring (original refactoring) is recorded so that It can later be applied to 
any dependent modules. For example, a rename refactoring of a library may 
include a class "MyNamespace::OldClass" as described above. The information 
that is recorded in this case will include that the "MyNamespace::OldClass" 
class has been renamed to "MyNamespace::NewClass". 

[Para 91] The writing/recording of meta information and the reading back of 
this information are relatively straightforward. In the currently preferred 
embodiment of the present invention, meta information regarding the original 
refactoring that is performed is written into an XML format. XML is used as 
XML provides a language-independent way of representing information that 
can be used with Java as well as other programming languages. However, a 
different format can be used for writing (and reading) this meta information if 
desired. In the presently preferred embodiment, the document type definition 
(or "DTD") for reading and writing refactoring information is in XML format as 
follows: 

1 : <?xml version="l .0" encoding="UTF-8" ?> 

2: <!ELEMENT refactor ( (rename-package | change-method-signature | 
rename-method | rename-field | rename-class)* ) > 
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3: 

4: <!ELEMENT declaring-class-name ( #PCDATA ) > 

5: 

6: <!ELEMENT rename-method ( declaring-class-name, 
declared-method-signature, old-method-name, new-method-name ) > 
7: <IATTLIST rename-method creation-time CDATA #REQUIRED > 
8: <!ATTLIST rename-method id CDATA #REQUIRED > 
9: <!ELEMENT declared-method-signature ( #PCDATA ) > 
1 0: <IELEMENT old-method-name ( #PCDATA ) > 
1 1 : <IELEMENT new-method-name ( #PCDATA ) > 
12: 
13: 

14: <!ELEMENT rename-class ( old-class-name, new-class-name ) > 

1 5: <!ATTLIST rename-class creation-time CDATA #REQUIRED > 

16: <!ATTLIST rename-class id CDATA #REQUIRED > 

1 7: <!ELEMENT old-class-name ( #PCDATA ) > 

1 8: <IELEMENT new-class-name ( #PCDATA ) > 

19: 

20: 

21 : <!ELEMENT rename-package ( old-package-name, new-package-name ) > 

22: <!ATTLIST rename-package creation-time CDATA #REQUIRED > 

23: <!ATTLIST rename-package id CDATA #REQUIRED > 

24: <!ELEMENT new-package-name ( #PCDATA ) > 

25: <!ELEMENT old-package-name ( #PCDATA ) > 

26: 

27: 

28: <IELEMENT rename-field ( declaring-class-name, old-field-name, 
declared-field-type, new-field-name ) > 

29: <!ATTUST rename-field creation-time CDATA #REQUIRED > 
30: <!ATTLIST rename-field id CDATA #REQUIRED > 
31 : <!ELEMENT old-field-name ( #PCDATA ) > 
32: OELEMENT declared-field-type ( #PCDATA ) > 
33: <IELEMENT new-field-name ( #PCDATA ) > 
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34: 
35: 

36: <!ELEMENT change-method-signature ( declaring-class-name, 
declared-method-name, old-method-signature, new-return-type?, 
new-parameters? ) > 

37: <!ATTLIST change-method-signature creation-time CDATA #REQUIRED > 

38: <!ATTLIST change-method-signature id CDATA #REQUIRED > 

39: <!ELEMENT declared-method-name ( #PCDATA ) > 

40: <IELEMENT old-method-signature ( #PCDATA ) > 

41 : <!ELEMENT new- return -type ( #PCDATA ) > 

42: <IELEMENT new-parameters ( parameter+ ) > 

43: <!ELEMENT parameter ( parameter-name, parameter-type, 
default-value?, old-index, new-index ) > 

44: <!ELEMENT parameter-name ( #PCDATA ) > 

45: <IELEMENT parameter-type ( #PCDATA ) > 

46: <!ELEMENT default-value ( #PCDATA ) > 

47: <IELEIV1ENT old-index ( #PCDATA ) > 

48: <IELEMENT new-index ( #PCDATA ) > 

[Para 92] As shown above, a refactoring of a dependee module may include 
refactoring operations which would be of interest in the subsequent 
refactoring of one or more dependent module(s). These operations include: 
renaming a package, changing a method signature, renaming a method, 
renaming a field, and/or renaming a class. As described above, the 
methodology of the present invention provides for capturing certain 
information about the refactoring of the dependee module. The above DTD 
specifies the information that is captured. As shown, information about the 
dependee module before and after the refactoring are recorded. For instance, 
as illustrated at lines 1 4-1 8, when a class is renamed the old (i.e., outdated) 
class name prior to the refactoring and the new class name after the 
refactoring are collected. Information before and after the refactoring Is 
collected so that this information can be subsequently used to perform a 
corresponding refactoring of a dependent module(s). 
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[Para 93] The captured information is tlien typically stored for later use. The 
captured information can be stored in any form, in any media, as desired. 
Alternatively, the information about the refactoring could be caught in real- 
time and streamed to others that would be interested in the original 
refactoring. In this respect it is not necessary that there be some lengthy delay 
or intervening period of time between the original refactoring (e.g., of the 
library) and the subsequent refactoring of the dependent modules (e.g., 
applications using the library). The information could be caught in real-time 
as the dependee was refactored and applied almost in real time through 
streaming to one or more dependent applications (modules). 

[Para 94] Asynchronous refactoring user interface 

[Para 95] Figs. 5A-B are screenshots of a preferred Java-based visual 
development or programming interface. Fig. 5A is a screenshot of a 
development or programming interface 500 including a distributed 
refactorings window 510 provided in the currently preferred embodiment of 
the present invention. As shown at Fig. 5A, the distributed refactorings 
window 510 includes two tabs: a pending refactorings tab 51 5 and a 
completed refactorings tab 520. The pending refactorings tab 51 5 provides 
for the display of a list of the refactorings that have occurred (e.g., in 
dependee modules). A user may consult the pending refactorings tab 51 5 to 
obtain a list of refactorings that have been discovered in projects (e.g., 
libraries) on which a given program or module is dependent and which should 
possibly be applied. (No pending refactorings are shown at Fig. 5A). It should 
be noted that the list of pending refactorings that is displayed typically will not 
include all refactorings that have been performed in dependee modules. There 
are some refactorings that only affect a single file and there is no need to 
capture or display information about that type of refactoring. For example, 
renaming a local variable that is not visible to a client (dependent) is generally 
not of interest and does not need to be captured or displayed. Other 
refactorings, however, may need to be distributed into other dependent 
modules in order to maintain compatibility. 
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[Para 96] In the presently preferred embodiment a dialog (not shown at Fig. 
5A) allows a developer performing a refactoring to decide whether to keep the 
refactoring Information and distribute It to others (I.e., for possible use In 
refactoring dependent modules). This dialog is provided as there are a 
number of circumstances in which a developer might not want to distribute 
information regarding a refactoring to others. For example, the developer may 
know that It Is not possible for anyone to have used a particular module, so 
there Is no need to capture Information about refactoring the module. A 
method may, for Instance, have been added In the current release of a library 
that has not yet been distributed to any users (e.g., applications using the 
library). In this case, If the new method Is renamed (rename refactored), there 
is no need to capture /record information about the refactoring of the new 
module as no one was able to use it yet. 

[Para 97] The completed refactorlngs tab 520 lists the refactorlngs that have 
previously been executed that were based on refactorlngs of the dependee 
files (library). The distributed refactorlngs window 510 enables a user (e.g., 
application developer) to track refactorlngs that may need to be performed as 
a result of dependencies on other modules and to determine the status of the 
effort to apply those refactorlngs to a given program (e.g., application). 

[Para 98] Fig. 5B Is another view of the development or programming 
Interface 500a which now includes a refactoring history window 550 provided 
In the currently preferred embodiment of the present Invention. The 
refactoring history window 550 displays information about refactorlngs that 
have been performed. The process of applying a refactoring that has been 
performed on a dependee software module to a dependent software module so 
as to maintain compatibility between two (or more) Interdependent modules Is 
described below in more detail. 

[Para 99] Refactoring with direct injection of symbols 

[Para 100] As described above, refactorlngs of dependent modules are 
facilitated by Injecting entries for symbol(s) Into symbol table(s) enabling 
refactorlngs of these dependent modules to be performed In an automated 
fashion. There are two mechanisms for injection of symbols supported in the 
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currently preferred embodiment of the present Invention which are referred to 
as "direct" and "indirect" Injections. 

[Para 1 01 ] Fig. 6 is a flowchart 600 illustrating the methodology of the present 
invention for refactoring of a dependent module with direct injection of entries 
for one or more symbols into symbol tables. The process starts with a given 
dependent module or application that is to be refactored based on a prior 
refactoring that has been performed. Assume that a refactoring has been 
performed that renamed a member (e.g., renamed a method) of a class of a 
library on which the application is dependent. For example, a method of the 
library may have changed its name from "oldMethodName" to 
"newMethodName". In order to apply the same refactoring to the application, 
the symbol injection methodology of the present invention essentially provides 
for "faking" the application (existing code) into thinking that the renamed 
member (i.e., oldMethodName) is still present in the library. In this case of 
renaming a method of a class, the class still exists in the library, but a class 
member (i.e., the oldMethodName method of the class) that may be used by 
the application no longer exists in the library as it has been renamed. The 
present invention provides for a symbol entry representing this class member 
(i.e., the oldMethodName) to be injected into the symbol table so that the rest 
of the application will think that it is present and will be able to use it in 
performing a refactoring of the application. 

[Para 102] At step 601 , the refactoring of the dependent module (e.g., 
application) commences with reading meta information about the original 
refactoring. In this case, this includes determining (looking up) the name of 
the method before the rename refactoring (oldMethodName) and after the 
rename refactoring (newMethodName) from the meta information about the 
refactoring of the library that has been previously captured. At step 602, 
symbol table entry(ies) are created based on the meta information. For 
instance, a symbol is created for the method with the name before the 
refactoring (e.g., the name oldMethodName that no longer actually exists in 
the library). At step 603, the created symbol(s) is injected (copied) into the 
symbol table (e.g., compiler symbol table). It should be noted that this symbol 
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table entry is temporary and only exists in the symbol table for as long as 
needed to perform the refactoring of the application. It is removed after the 
refactoring Is complete as provided below. 

[Para 103] At step 604, the refactoring of the dependent module (e.g., 
application) is performed based on the meta information about the original 
refactoring. For instance, the refactoring of the application is performed in an 
automated fashion by replacing instances of oldMethodName with 
newMethodName. In the currently preferred embodiment, this refactoring is 
performed by the system with the assistance of the compiler (compiler- 
assisted refactoring). Every place that the oldMethodName is found by the 
complier in the application is identified and each such instance of 
oldMethodName is replaced correctly with the newMethodName. When this 
refactoring of the application is complete, the temporary symbol(s) injected at 
step 603 are removed from the symbol table at step 605. In this case, the 
symbol entry injected into the symbol table to represent the oldMethodName 
is removed from the symbol table. 

[Para 104] The SymbolCreator class of the presently preferred embodiment 
that creates symbols for injection into symbol tables is as follows: 

1 : package com.borland.jbuilder.refactor.async; 

2: 

3: import com.borland.primetime.util.*; 

4: 

5: import com.borland.jbuilder.jam.*; 
6: import com.borland.jbuilder.java.*; 
7: import com.borland.jbuilder.node.*; 

9: import com.sun.tools.javac.code.*; 

1 0: import com.sun.tools.javac.code.Symbol.*; 

11: 

1 2: public class SymbolCreator { 

1 3: private JBProject project; 

1 4: private ClassSymbol classSymbol; 
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15: 

1 6: private ClassCloner classCloner; 
17: 

1 8: /** 

1 9: * Constructor when a class already exists. Will lookup the 

20: * classsymbol required for adding members 

21: * 

22: * @param project JBProject 

23: * @param existingClass JamClass 

24: */ 

25: public SymbolCreatorOBProject project, 
26: JamClass existingClass) { 

27: this. project = project; 
28: classSymbol = 

Memberlnjector.findClassSymboKexistingClass.getNameQ, project); 

29: } 
30: 

31: /** 

32: * Constructor when the class does not exist and needs to be 

33: * created from a cloned class 

34: * 

35: * @param project JBProject 

36: * @param existingClass JamClass - this the class that will used 

37: * to clone the new class 

38: * @param newClassName String - the name of the new class once 
cloned 

39: */ 

40: public SymbolCreatorOBProject project, 
41: JamClass existingClass, 

42: String newClassName) { 

43: this. project = project; 

44: classCloner = new ClassCloner(project, existingClass, 
newClassName); 
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45: classSymbol = classCloner.getNewClassSymbolQ; 

46: } 

47: 

48: 

49: 

50: public void clearSymbolsO { 

51: if (classCloner != null) { 

52: classCloner.removeClonedClassO; 

53: } 

54: project.getCompilerManagerO.purgeCompilerContextO; 

55: } 

56: 

57: /** 

58: * From methodName and methodType create a method symbol for the 

59: * class passed in the contractor 

60: * 

61 : * @param methodName String 

62: * @param methodType JamMethodType 

63: * @return l\4ethodSymbol 

64: */ 

65: public MethodSymbol addMethodSymbol(String methodName, 
66: JamMethodType methodType) { 

67: classSymbol = getClassSymbolQ; 
68: 

69: StringG parameters = 

JamUtil.convertJamTypeToString(methodType.getParameters()); 

70: String returnType = methodType.getReturnTypeO.toTextO; 

71 : MethodSymbol newMethod = 
Memberlnjector.addMethodSymboKclassSymbol, 
72: Flags. PUBLIC, 
73: methodName, 
74: returnType, 
75: parameters. 
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76: EmptyArrays.STRING_EMPTY_ARRAY, 

77: project); 

78: return newMethod; 

79: } 
80: 

81: /** 

82: * From fromFieldName and fieldType create a new VarSymbol for 
83: * the class passed in the constructor 
84: * 

85: * @param fromFieldName String 
86: * @param fieldType JamType 
87: * @return VarSymbol 

88: */ 

89: public VarSymbol addFieldSymbol(String fromFieldName, JamType 
fieldType) { 

90: classSymbol = getClassSymbolO; 
91: 

92: VarSymbol newField; 

93: newField = Memberlnjector.addFieldSymbol(classSymbol, 

94: Flags.PUBLIC, 

95: fromFieldName, 

96: fleldType.toTextO, 

97: project); 

98: return newField; 

99: } 

100: 

101: /** 

1 02: * Get the class symbol found during construction of this class 

103: * 

1 04: * @return ClassSymbol 
105: */ 

1 06: public ClassSymbol getClassSymbolO { 
1 07: return classSymbol; 
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108: } 
109: } 

[Para 105] The above SymbolCreator class includes two constructors. As 
shown at lines 25-29, a first constructor is used when a class already exists. 
This constructor looks up the ClassSymbol needed for adding members. The 
second constructor at lines 40-46 is used when the class does not exist and 
needs to be created from a cloned class. This constructor calls the 
ClassCloner (described below) to clone the class and gets the ClassSymbol as 
illustrated at lines 44-45. 

[Para 106] As shown in the addMethodSymbol routine at lines 65-79, a method 
symbol is then created for the class passed into the constructor from the 
methodName and methodType. As shown, the addMethodSymbol routine of 
the Memberlnjector class is then called to inject the symbol into the symbol 
table. The addFleldSymbol method at lines 89-99 creates a new VarSymbol for 
the class passed into the constructor based on the fromFieldName and 
fieldType. The addFieldSymbol method of the Memberlnjector class is called 
to inject the symbol as shown at lines 93-97. 

[Para 107] The Memberlnjector class of the presently preferred embodiment 
that performs the direct injection of symbols is as follows: 

1: package com.borland.jbuilder.java; 
2: 

3: import com.sun.tools.javac.code.Symbol. ClassSymbol; 

4: import com.sun.tools.javac.code.Symbol.VarSymbol; 

5: import com.sun.tools.javac.code.Symbol.MethodSymbol; 

6: import com.borland.jbuilder.java.filter.FilterHelper; 

7: import com.borland.primetime.node.Project; 

8: import com.sun.tools.javac.jvm.ClassReader; 

9: import com. sun.tools.javac.util. Name; 
1 0: import com.sun.tools.javac.util.Name.Table; 
1 1 : import com.sun.tools.javac.comp.Check; 
12: import com.sun.tools.javac.comp.Env; 
1 3: import com.sun.tools.javac.util.*; 
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14: import com.sun.tools.javac.code.Type; 

1 5: import com.sun.tools.javac.code.Symtab; 

16: import com.borland.jbuilder.jam.Jaml\1ethodType; 

1 7: import com.borland.jbuilder.jamJamType; 

1 8: import com.sun.tools.javac.code.Type.MethodType; 

1 9: import com.borland.primetime.vfs.VFS; 

20: 

21 : public class Memberlnjector { 

22" I** 

23: * Lookup for an existing ClassSymbol 
24: * @param fullName String Full name of the class we are 
looking for. 

25: * @param project Project Projecxt used for access to 
necessary context information. 

26: * @return ClassSymbol The found ClassSymbol or null. 

27: */ 

28: static public ClassSymbol firidClassSymbol(String fullName, 
Project project) { 
29: synchronized 

(CompilerManager.instance(project).getManager(true). 
30: getContextLockO) { // Alway get the JSp one (for now.) 

31: return FilterHelper.lookupClass(fullName, 
32: CompilerManager.instance(project).getManager(true). 
33: getProjectContextO); // Alway get the JSp one 

(for now.) 
34: } 
35: } 
36: 

37: /** 

38: * Removes a ClassSymbol from the ClassSymbol's table. (For 
cleanup purposes) 

39: * @param fullName String Full name of the class to remove from 
the table 
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40: * @param project Project Project for access to necessary 
context information. 
41: */ 

42: static public void removeClassSymbol(String fullName, Project 
project) { 

43: synchronized 

(CompilerManager.instance(project).getManager(true). 
44: getContextLocl<()) { // Alway get the JSp one (for now.) 
45: Name.Table names = 

Name.Table.instance(CompilerManager.instance(project). 
46: getl\1anager(true).getProjectContext()); //Alway get 

the JSp one (for now.) 

47: Name name = names.fromString(fullName); 
48: 

ClassReader.instance(CompiierManager.instance(project).getManager( 
true). 

49: getProJectContext()).classes.remove(name); // Alway 

get the JSp one (for now.) 
50: Check context = 

Check.instance(CompilerManager.instance(project). 

51 : getManager(true).getProjectContext()); 

52: context.compiled.remove(name); // Alway get the JSp one 

(for now.) 

53: } 

54: } 

55: 

56: /** 

57: * Lookup for a Field in an owner ClassSymbol. 
58: * @param owner ClassSymbol 
59: * @param name String name of the field 
60: * @param project Project Project for access to necessary 
context information. 

61 : * @param env Env Used to get the Scope object on which to 
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perform the lookup. 



62 
63 
64 



* (©return VarSymbol The found field symbol or null. 

*/ 

static public VarSymbol findFieldSymboKCIassSymbol owner, 
String name, Project project, Env env) { 
65: try{ 

66: synchronized 

(CompilerManager.instance(project).getManager(true). 
67: getContextLockO) { // Alway get the JSp one (for now.) 

68: Context context = 

CompilerManager.instance(project).getManager(true). 
69: getProjectContextO; // Alway get the JSp one 

(for now.) 

70: ClassSymbol csym = 

FilterHelper.lookupClass(owner.flatNameO, context); 
71 

if (csym == null) { 
return null; 

} 



72 
73 
74 
75 
76 
77 
78 
79 
80 
81 
82 
83 
84 
85 
86 



return FilterHelper.lookupVar(csym, name, context, env); 

} 

} 

catch (Exception ex) { 
return null; 

} 



} 



1** 

* Adds a field symbol to the "owner" ClassSymbol 

* @param owner ClassSymbol The ClassSymbol to which to add the 
field symbol. 

87: * @param flags long Modifiers of the field symbol 
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88: * @param varName String Name of the field symbol 
89: * @param sType String Type of the field symbol 
90: * @param project Project Project for access to necessary 
context information. 

91 : * @return VarSymbol The newly created field symbol 
92: */ 

93: static public VarSymbol addFieldSymbol(ClassSymbol owner, 
flags, 

94: String varName, String 

sType, 

95: Project project) { 

96: assert owner 1= null; 
97: try{ 

98: synchronized 

(CompilerManager.instance(project).getManager(true). 
99: getContextLockO) { // Alway get the JSp one (for now.) 

1 00: Type type = getTypeFromString(sType, project); 
1 01 : assert type != null; 

102: VarSymbol ret = null; 

103: Name.Table names = 

Name.Table.instance(CompilerManager.instance( 
1 04: project). 
105: getManager(true). 

1 06: getProjectContextO); // Alway get the JSp one 

(for now.) 

1 07: Name name = names.fromString(varName); 

108: 

1 09: ret = new VarSymbol(flags, name, type, owner); 
1 1 0: owner.membersO.enter(ret); 
111: return ret; 
112: } 
113: } 

1 1 4: catch (Exception ex) { 
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1 1 5: return null; 
116: } 
117: } 
118: 

119: /** 

1 20: * Lookup for a method in an owner ClassSymbol. 
121: * 

1 22: * @param owner ClassSymbol 
1 23: * @param name String name of the method 
1 24: * @param retType String Return type of the method 
125: * @param parameterTypes String [] Parameter types fror the method 
126: * @param project Project Project for access to necessary 
context information. 

127: * @param env Env Used to get the Scope object on which to 

perform the lookup. 
1 28: * @return MethodSymbol The found method symbol or null. 
129: */ 

1 30: static public MethodSymbol findMethodSymbol(ClassSymbol owner, 
131: String name, String 

retType, 

132: StringD 

parameterTypes, 
133: Project project, Env 

env) { 

134: assert owner != null; 
135: try{ 

1 36: synchronized 

(CompilerManager.instance(project).getManager(true). 
1 37: getContextLockO) { // Alway get the jSp one (for now.) 

1 38: Context context = 

Compilerl\/lanager.instance(project).getManager(true). 
1 39: getProjectContextO; // Alway get the JSp one 

(for now.) 
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140: JamType[] paramTypes = newJamType 
[parameterTypes .length] ; 



for (int i = 0; I < paramTypes. length; { 
paramTypes[i] = JamType.fromText(parameterTypes[i]); 

} 



141 
142 
143 
144 

145: String signature = 

JamMethodType.createSignatureOamType.fromText( 
1 46: retType), paramTypes); 

1 47: MethodSymbol ret = FilterHelper.lookupFun(owner, name, 

signature, 
148 
149 
150 
151 
152 
153 
154 
155: } 
156 
157 
158 
159 



context, env); 
return ret; 

} 

} 

catch (Exception ex) { 
return null; 

} 



Jit* 

* Adds a method symbol to owner class symbol 

* @param owner ClassSymbol The ClassSymbol to which needs to 
add the new method symbol 

1 60: * @param flags long Modifiers of the new method symbol 

* @param methodName String Name of the new method symbol 

* @param retType String Return type of the new method symbol 

* @param parameterTypes String[] Parameter types for the new 
method symbol 

1 64: * @param thrownTypes String[] Exceptions thrown by the new 
method symbol 

1 65: * @param project Project Project for accessing necessary 
context information. 



161 
162 
163 
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166 



167 
168 



* 



(©return MethodSymbol The newly created MethodSymbol 



*/ 

static public MetliodSymbol addMethodSymbol(ClassSymbol owner, 
long flags, 

169: String methodName, 

String retType, 

1 70: StringU 

parameterTypes, 
171 



172 
173 
174 
175 



StringQ thrownTypes, 
Project project) { 



assert owner 1= nul 
try{ 

synchronized 



(CompilerManager.instance(project).getManager(true). 
1 76: getContextLockO) { // Alway get the jSp one 

(for now.) 

1 77: Type resType = getTypeFromString(retType, project); 
1 78: assert resType 1= null; 
1 79: Context context = 

CompilerManager.instance(project).getManager(true). 
1 80: getProjectContextO; // Alway get the JSp one 

(for now.) 
181 
182 
183 
184 
185 
186 
187 
188 
189 

project)); 
190: } 



MethodSymbol ret = null; 

Name.Table names = Name.Table.instance(context); 
Name name = names.fromString(methodName); 

ListBuffer paramTypes = new ListBufferO; 
ListBuffer thrTypes = new ListBufferO; 

for (int i = 0; i < parameterTypes. length; i++) { 
paramTypes. append(getTypeFromString(parameterTypes[i], 
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191 
192 
193 



for (int j = 0; i < thrownTypes. length; { 
thrTypes.append(getTypeFromString(thrownTypes[i], 



project)); 



194 
195 
196 



MethodType mType = new MethodType(paramTypes.toList(), 



resType, 



197 
198 
199 

200 
201 



thrTypes.toListO, owner.type.tsym); 
ret = new MethodSymbol(flags, name, mType, owner); 
owner.membersO.enter(ret); 
return ret; 



202: } 

203: catch (Exception ex) { 

204: return null; 

205: } , 

206: } 

207: 

208: /** 

209: * Converts a String represented parameter type to a compiler's 
Type. 

210: * @param sType String String represented type. 

211: * @param project Project Project used for access to necessary 

context information. 
212: * @return Type The converted compiler Type. 
213: */ 

214: private static Type getTypeFromStrlng(String sType, Project 

project) { 
215: Type type = null; 
216: 

217: Symtab syms = 
Symtab.lnstance(CompilerManager.lnstance(project).getManager(true). 
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getProjectContextO); // Alway get the JSp one (for now.) 
218: 

219: if (sType.equalsC'int")) { // NORES 

220: type = syms.intType; 

221: } 

222: else if (sType.equals("byte")) { // NORES 

223: type = syms.byteType; 

224: } 

225: else if (sType.equals("char")) { // NORES 

226: type = syms.charType; 

227: } 

228: else if (sType.equals("short")) { // NORES 

229: type = syms.shortType; 

230: } 

231 : else if (sType.equalsC'long")) { // NORES 

232: type = syms.longType; 

233: } 

234: else if (sTypcequalsffloat")) { // NORES 

235: type = syms.floatType; 

236: } 

237: else if (sType.equalsC'double")) { // NORES 

238: type = syms.doubleType; 

239: } 

240: else if (sType.equalsC'boolean")) { // NORES 

241: type = syms.booleanType; 

242: } 

243: else if (sType.equalsCVoid")) { // NORES 

244: type = syms.voidType; 

245: } 

246: else if (sType.indexOf("[") !=-!){ // NORES 

247: type = syms.arraysType; 

248: } 
249: 
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250 
251 
252 
253 
254 
255 
256 



else { 

type = findClassSymboKsType, project).type; 

} 

return type; 



} 



} 

[Para 108] Of particular interest, the addFieldSymbol method of the above 
Memberlnjector class adds a field symbol to the "owner" ClassSymbol as 
provided at lines 93-1 1 7. The method returns a VarSymbol, which is the 
newly created field symbol. The Memberlnjector class also includes an 
addMethodSymbol routine which performs a similar function for adding a 
method symbol to a given ClassSymbol. The addMethodSymbol routine is 
shown above at lines 168-206. The routine returns a newly created 
MethodSymbol. 

[Para 1 09] Refactoring with indirect injection of symbols 

[Para 1 1 0] Fig. 7 is a flowchart 700 illustrating the methodology of the present 
invention for refactoring of a dependent module with indirect Injection of 
symbols into symbol tables. The indirect injection of symbol(s) is similar to 
direct injection. However, instead of creating a symbol table entry and directly 
injecting it into the symbol table(s), the symbols are injected indirectly by 
creating source code for the old version (i.e., the outdated version as in effect 
before the refactoring). When this source is parsed /attributed, the symbol 
table entries are then indirectly injected as a side effect. 

[Para 1 1 1] At step 701, the process begins with decompiling the class of the 
dependee module (library) that was originally refactored. In the currently 
preferred embodiment, the new class of the dependee module (i.e., the class 
of the library after refactoring) is decompiled. At step 702, a temporary "stub" 
class is created based on the decompiled library class. The "stub" class that is 
created to represent this library class typically includes "stub" methods and 
"stub" fields. This stub class is created for the sake of the application "seeing" 
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it. The source code of the stub class Is then used to create the symbol table 
entries for the class and (indirectly) insert them into the symbol table. 

[Para 1 1 2] At step 703, the stub class is then refactored to represent the old 
class (i.e., the outdated version of the class before the original refactoring of 
the library) based on the collected meta information about the original 
refactoring. In this manner the stub class is revised to include the old method 
names, field names, and so forth as were in effect before the refactoring. In 
other words, the stub class is fixed up so that it now represents the outdated 
version of the class (before the refactoring) that does not exist anymore. In 
effect, this recreates the old (outdated) version of the class for use in 
refactoring of the application. 

[Para 1 13] After the stub class has been created and refactored it Is handed off 
to the parsing system. At step 704, the parsing system parses/attributes the 
stub class and as a side effect the symbol(s) of the stub class are entered into 
the appropriate symbol table(s) as this parsing is performed. This serves to 
indirectly inject the symbol(s) into the symbol table(s). At step 705, the 
refactoring of the dependent module (application) is then performed based on 
meta information about original refactoring. This refactoring is performed in 
the same manner as described above. After the refactoring is completed, 
clean-up operations are performed at step 706. The clean up phase is similar 
to that described above. However, in this case both the temporary symbol(s) 
injected into the symbol table(s) and the stub class are removed after the 
refactoring is complete. 

[Para 1 14] The ClassCloner class of the presently preferred embodiment that 
performs the indirect injection of symbols is as follows: 

1 : package com.borland.jbuilder.refactor.async; 

2: import java.io.*; 

3: 

4: import com.borland.primetime.vfs.*; 

5: 

6: import com.borland.jbuilder.jam.*; 
7: import com.borland.jbuilder.java.*; 
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8: import com.borland.jbullder.jom.*; 
9: import com.borland.jbullder.node.*; 



10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 



import com.borland.jbuilder.repository.* 

import com.sun.tools.javac.code.*; 
import com.sun.tools.javac.code.Symbol. 

public class ClassCloner { 
private J BProject project; 
private JomFlle newClonedJomFile; 
private JamClass existingJamClass; 
private String newClassName; 



y ** 

* Will clone a class from existingJamClass and then rename the 

* package, class and constructors based on newClassName 

* 

* @param project JBProject 

* @param existingJamClass JamClass 

* @param newClassName String 

*/ 

public ClassClonerOBProject project, JamClass existingJamClass, 



String newClassName) { 



31 
32 
33 
34 
35 
36 
37 



this. project = project; 

this. existingJamClass = existingJamClass; 

this. newClassName = newClassName; 

} 



jicie 

* Clones the new class from existingJamClass and the 
newClassName, parses 

38: * the newly create class which has the side affect of putting 
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it in tlie symbol 

39: * table and then returns the ClassSymbol from the symbol table 
40: * 

41 : * @return ClassSymbol 

42: */ 

43: public ClassSymbol getNewClassSymbolQ { 
44: createNewClassQ; 

45: return Memberlnjector.findClassSymbol(newClassName, project); 

46: } 

47: 

48: private void createNewClassQ { 
49: if (newClonedJomFile == null) { 

50: //Get an uri for the new class from it's name and using the 
projects paths 

51: UrI newUrl = JomUtil.getUrlFromClassName(project, 
newClassName); 
52: 

53: ClassEntry ce = 

project.getRepositoryO.getClassEntry(existingJamClass.getNameO); 

54: UrI classFileUrl = ce.getFlleO; 

55: //Will contain the source code for the existing class 

(directly or decompiled) 

56: String newSource = null; 

57: 

58: //Try to create by decompiling if the compiled class file 
exists 

59: if (ClassFileUrl 1= null && VFS.exists(classFileUrl)) { 

60: ClassStubSource stub = null; 

61 : stub = new ClassStubSource(classFileUrl); 

62: newSource = stub.toStringQ; 

63: } 

64: //Else copy the source content from the source file 
65: else{ 
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66: SourceEntry se = ce.getSourceQ; 

67: if (se != null){ 

68: try{ 

69: newSource = new 
String(VFS.getBuffer(se.getFile()).getContent()); 

70: } 

71 : catch (lOException ex) { 

72: } 

73: } 

74: } 

75: if (newSource == null) { 

76: return; 

77: } 
78: 

79: //Create a Sourcelnfo for newSource and set to newUrl 

80: Sourcelnfo si = project.getSourcelnfoManagerO.get(newSource); 

81: si.setUrl(newUrl); 

82: 

83: //Create an instance of JomFile so we can fix up the class 

and package 

84: //names 

85: newCionedJomFlle = JomFile. instance(project, si, newUrl); 

86: if (newClonedJomFile 1= null) { 

87: JomClass jomClass = 

newClonedJomFile.getClass(existin9JamClass.getType()); 
88: 

89: if OomClass 1= null) { 

90: //Set's the new class name (will fix up the classname 
and constructors) 

91 : jomClass.setNameOavaNames.getClassName(newClassName)); 

92: } 

93: String newPackageName = 
JavaNames.getPackageName(newClassName); 
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94: String oldPackageName = 

JavaNames.getPackageName(existingJamClass.getName()); 

95: 

96: //If the new class is in a different package than fix up 
the package statement 

97: if (!newPackageName.equals(oldPackageName)) { 
98: 

newClonedJomFile.getPackage().setPackageName(newPackageName); 
99: newClonedJomFile.addlmport(newJomlmport(oldPackageName 

+ ".*")); 

100: } 

1 01 : //Now commit changes which also enters the symbols into 
the symbol table 
102: //for the new class 

1 03: newClonedJomFile.commitAndEnterSymbols(false); 

104: } 

105: } 

106: } 

107: 

108: /** 

1 09: * Removes the cloned class 
110: */ 

111: public void removeClonedClassO { 
112: try{ 

113: if (newClonedJomPile 1= null) { 

114: VFS.delete(newClonedJomFile.getUrlO); 

1 1 5: newClonedJomFile = null; 

116: } 

117: } 

1 1 8: catch (iOException ex) { 
119: } 
120: } 
121:} 
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[Para 1 1 5] The above routine clones an existing class of a program and then 
changes it to represent an outdated (or old) class as in effect prior to a 
refactoring. As illustrated above at line 44, a createNewClass method is called 
to create a clone based on an existing class. As described below, the 
createNewClass method clones an existing class (existingJamClass) and then 
fixes it up. The newly created class is then parsed which has the side effect of 
inserting symbols in the symbol table. The ClassSymbol is then returned from 
the symbol table through the call to the findClassSymbol method of 
Memberlnjector as provided at line 45. 

[Para 1 16] When the createNewClass method is called, it gets a URL for the new 
class from its name and using the project's paths as provided at line 51 . The 
source (newSource) for the existing class is then obtained either directly or by 
decompiling the compiled class file. A Sourcelnfo is created for the newSource 
and set to the new URL as provided at lines 80-81 . Next, an instance of 
JomFile is created to enable the class and package names of the cloned class 
to be fixed up. The name and constructors of the cloned class are fixed up as 
illustrated at lines 89-94. The package statement is also fixed up if the new 
class is in a different package as provided at lines 97-1 00. The call to the 
commitAndEnterSymbols method at line 103 commits the changes made to the 
cloned class which also enters the symbols into the symbol table. 

[Para 1 1 7] Direct and indirect symbol injection 

[Para 11 8] It should be noted that in the currently preferred embodiment, both 
of the above approaches (direct and indirect injection) are typically used for 
refactoring of dependent modules. The following will described this in general 
terms using a typical example of a refactoring of a dependent module (e.g., 
application) based on an original refactoring of a class of dependee module 
(e.g., a library). In the case of refactoring of a dependent application based on 
an original refactoring of a class of the library, the general process is as 
follows. First, the original version of the library class is decompiled into 
source code as described above and a "stub" class is created to represent the 
old version of the class (before the refactoring) as illustrated in the above 
ClassCloner module. The source code for this stub class is then used as the 
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basis for indirect injection of the symbols for the class into the symbol table(s). 
Next, with respect to members of the class (e.g., fields and methods of the 
class), the injector module (Memberlnjector) is used for direct injection of 
those symbol(s). Thus, for a refactoring of the class both mechanisms for 
injecting the symbols are generally used in the currently preferred 
embodiment of the present invention. 

[Para 1 19] While the invention is described in some detail with specific 
reference to a single-preferred embodiment and certain alternatives, there is 
no intent to limit the invention to that particular embodiment or those specific 
alternatives. For instance, use of the Java programming language is not 
necessary to the invention, and the present invention may be implemented in a 
variety of system architecture and processing environments. Those skilled in 
the art will appreciate that modifications may be made to the preferred 
embodiment without departing from the teachings of the present invention. 
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